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Databases are an indispensable resource for retrieving up-to-date information. How- 
ever, curious database operators may be able to find out the users' interests when the 
users buy something from the database. For these cases, if the digital goods have the 
identical prices, then a fc-out-of-n oblivious transfer protocol could help the users to 
hide their choices, but when the goods have different prices, this would not work. In 
this paper, we propose a scheme to help users to keep their choices secret when buying 
priced digital goods from databases. 

O 

*t ', 1. Introduction 

00 

(N ■ i am quite sure that all readers are familiar with digital libraries, such as the digital libraries 

of ACM, IEEE and SIAM. These libraries provide researchers with a comprehensive resource 
of published papers, and users can easily retrieve their desired papers by visiting these 

o 

libraries. Recall how we retrieve data from digital libraries: we log in the system, select our 
desired ones and download them. If one does not own a membership of a database, he would 
^ . have to pay for the papers he reads, perhaps according to the length of the publication. This 

process is convenient, but we undertake the risk of revealing our private research interests 
to the database operators. 

If every paper has the same price, this problem can be resolved perfectly: suppose that 
there are n publications in the library and we are interested in k of them, then by k-out-oi-n 
oblivious transfer, we pay for some k publications while revealing nothing about our choices. 
In other word, the operator learns nothing but k, and could get the payment by adding up 
the prices for the k sold items. 

However, it is naive to assume that all publications have the same price. Nowadays, 
most papers are priced according to their lengths, perhaps one dollar per page. A more 
scientific way (although not perfect) is to price the data according to the number of bits it 
contains. More formally, here we may view the database as a binary string x = x\Xi • • ■ x n 
of length n, and every bit has the same weight. Then the we could still use oblivious transfer 
to buy our desired bits from the library, leaking nothing but the number of bits we pay for. 
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This scheme is not efficient (since the number of bits can be very large), and a more 
serious problem is that we should not assume every bit to have the same value. Instead 
of finding a method to assign prices for different goods, we would rather let the database 
operator to assign the value herself himself: a two-page communication may cost you 100 
dollars, while a 200-page review may cost only 1 dollar. After all, we let the operator to 
assign the prices himself. 

Now we consider the general problem: the database has n items, namely mi, ni2, • • • , m n . 
Each item m.j(l < i < n) has its own weight pi. Let a±, 0-2, ■ ■ ■ > o"fc> a subset of {1, 2, • • • , n}, 
be the choices of a user, the goal is to leak m aj {\ < j < k) to the user while revealing 
nothing but ^jPdj to the database operator. This is a special case of oblivious transfer, we 
denote it weighted oblivious transfer. 

Organization. In the rest of this section we discuss in more detail traditional oblivious 
transfer and weighted oblivious transfer. Section 2 presents two protocols for weighted 
oblivious transfer. Section 3 concludes the paper. 

1.1. A short review of oblivious transfer 

Oblivious Transfer (OT) refers to a kind of two-party protocols where at the beginning 
of the protocol one party, the sender, has an input, and at the end of the protocol the 
other party, the receiver, learns some information about this input in a way that does not 
allow the sender to figure out what it has learned [1]. Oblivious transfer is one of the key 
components of many cryptographic protocols and a fundamental primitive for cryptogra- 
phy and secure distributed computation [2, 3, 4]. The concept of oblivious transfer was 
proposed by Rabin [5], since then, many flavors of oblivious transfer were introduced and 
analyzed [5, 6, 7, 8, 9]. Now oblivious transfer is one of the most remarkable achievements 
in foundation of cryptography. The main flavors of oblivious transfer are as follows: 

• Original oblivious transfer (OT)[5]. For OT, the sender has only one secret, m, and 
would like to have the receiver obtain m with probability 0.5. On the other hand, the 
receiver does not want the sender to know whether it gets m or not. 

• l-out-of-2 oblivious transfer(OT 2 1 )[6]. For OT\, the sender has two secrets, m\ and 
1712, and would like to give the receiver one of them at the receiver's choice. Again, 
the receiver does not want the sender to know which secret it chooses. 

• 1-out-of-n oblivious transfer(OT r [)[7]. OT\ is a natural extension of OT 2 l to the case of 
n secrets, in which the sender has n secrets mi, 7712, • • • , m n and is willing to disclose 
exactly one of them to the receiver at its choice. 

• /c-out-of-?i oblivious transfer (OT%) [10]. For OT%, the receiver can receive only k mes- 
sages out of n messages sent by the sender. In general, one thinks that OT^ is exten- 
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sion of OT^ . It is obvious that a trivial OT% protocol can be obtained by performing 
OT^ protocol k times. 

Essentially, all these flavors are equivalent in the information theoretic sense [11], but 
their functions vary, intuitively, we may use the following relation to describe the relation 
among all four flavors: 

OT C OT\ C OTl C OT%. (1) 

There are many ways to construct an efficient oblivious transfer protocol. Classical 
oblivious transfer protocols are based on discrete logarithm [12, 13], the hardness of the 
decisional Diffie-Hellman problem [14] etc. 



1.2. Definition of weighted oblivious transfer 

To define the requirements of a weighted oblivious transfer protocol, we simply apply the 
requirements of general OT^ protocol (with minor revisions) [15] to it: for convenience, let 
m i, m 2, • ■ • , m n to be items and pi be the weight of rrii. 

Definition 1 A [k-out-of-n) weighted oblivious transfer should meet the following re- 
quirements: 

• Correctness. The protocol achieves its goal if both the receiver and the sender behave 
properly. That is, if both the receiver and the sender follow the protocol step by step, 
the receiver gets m (7i 's after executing the protocol with the sender, where o~i 's are the 
receiver's choices, and the sender learns Y^l=iPai(^ e -' the whole price of the goods). 

• Receivers' Privacy-indistinguishability. The transcripts corresponding to the receiver's 
different choices {a a i} and {abi}, {o~ a i} ^ {o~bi}, are computationally indistinguishable 
to the sender if the following equation is satisfied: 

%Pa ai = Zp* bi - (2) 

If the transcripts are identically distributed, the choice of the receiver is uncondition- 
ally secure. 

• Sender's Privacy-compared with ideal model. We say that the sender's privacy is guar- 
anteed if, for every possible malicious R which interacts with S, there is a simulator R' 
(a probabilistic polynomial time machine) which interacts with T such that the output 
of R' is computationally indistinguishable from the output of R. 

Remark. The weighted oblivious transfer also relies on the intractability of subset sub 
problem. The protocol implies that by the total price of the sold items, the sender cannot tell 
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which items the receiver bought. Although subset sum problem is know to be NP-complete, 
sometimes it is still solvable (consider the case where the prices are 1, 2, 4, 8, • • • , 2 n_1 , then 
the binary representation of the total price would betray the receiver's choice). However, 
for this case, even if we apply a trusted third party T, the problem still exists. This problem 
is solvable when the database is stored by more than one servers (recall PIR), but this is 
out of the scope of this paper. 



1.3. Comparing to priced oblivious transfer 

Perhaps the idea that of weighted oblivious transfer is similar to [16]. In [16], the notion 
of "priced oblivious transfer" is proposed. Informally, assume that a buyer first deposits 
a pre-payment at the hands of a vendor. The buyer should then be able to engage in a 
virtually unlimited number of interactions with the vendor in order to obtain digital goods 
(also referred to as items) at a total cost which does not exceed its initial deposit amount. 
After spending all of its initial credit, the buyer should be unable to obtain any additional 
items before depositing an additional pre-payment. For priced oblivious transfer, unlimited 
number of interactions and prepayment is required, while these requirements relax in this 
paper. However, for weighted oblivious transfer, the receiver would disclose how much, 
when to the sender, since we do not assume that the receiver interacts with the sender 
many times. Comparing to priced oblivious transfer, weighted oblivious transfer is used 
when the receiver would like to buy the desired items once at the same time. 

2. Weighted oblivious transfer 

The idea of our first protocol is straightforward. The sender locks the ever item mi 
with pi different locks. In this way, only with all pi locks can the receiver get m,;. This 
implies that the sender needs to generate Y17=i Pi keys, and with Yli=i P&i locks and keys, 
the receiver could unlock the locks for m CTi 's. By using a X^i=i Po-i-out-of-^™ =1 pj oblivious 
transfer, the sender could leak the corresponding keys to the receiver without knowing the 
chosen ones, thus unable to figure out the receiver's choices. For simplicity, the best(i.e., 
most efficient) lock should be symmetric key encryption scheme. 

Protocol 1 

In this protocol, the sender has Ya=iP^ P a i rs °f (different) keys, denoted by Kij(i £ 
{1,2, • • • ,n},j G {1,2, ■ • • ,pi}). Intuitively, the sender locks rrii with K^s. 
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Input: The receiver's input is composed of k numbers o~i, o~2, ■ ■ ■ , which is a subset 
of {1, 2, . . . , n}, and the sender's input is composed of n priced items mi, 1712, • • • , Tn n , the 
weight (price) of item m; is 

Output: The receiver's outputs are m CTl , m CT2 , . . . , m CTfe , and the sender's output is T^ =1 p ai . 

• Step 1 The sender encrypts the items mi, ttt-2, • • • , m n with the encryption keys. For 
rrii, this is done by computing Ex iL (.Ejf j2 (■ ■ ■ (Ek w . ( m i)) ■ ' ' )• That is, m^ is encrypted 
by pi locks: Kn, • • • , Ki p . respectively. 

• Step 2 The sender sends all the ciphertexts to the receiver. 

• Step 3 By ^f=i ^a»-° u t-of- oblivious transfer, the sender reveals the keys for 
all m CTi 's, while learning nothing about the receiver's choices. 

• Step 4 With the keys, the receiver easily decrypts and learns all m ai 's (and nothing 
else). 

This protocol is straightforward, and we do not prove that it is actually a weighted 
oblivious transfer in a formal way. Informally, assume the security of Yli=i Po-i-out-of- 
Y17=iPi oblivious transfer protocol used in step 3, the sender leaks nothing but Y^l=iP<^i 
during step 3, the only communication from the receiver to the sender. Also, the receiver 
could unlock no more than X^iPo-j locks, thus leans no more than what "costs" X/i=iPov 
Although the protocol is not efficient enough, it is the cornerstone of the next protocol. 

Remark. When the protocol is applied by databases, the first two steps are done before 
transactions. That is, the database publishes the encrypted items online and everyone could 
download them. When interested in some of the items, the user interacts with the database 
operator and completes the last two steps. In this way, they would not need to communicate 
the whole encrypted data, which turns out to be huge. Also, the items are encrypted only 
once for all users. 



2.1. Making our protocol efficient 

It is not hard to show that protocol 1 needs 0(^2^=1 Pi) encryptions, this number is 
clearly impractical, at least sometimes. In this subsection, we propose a very efficient 
protocol which only needs 0(n) encryptions. 

If for any m.j, if there is way to divide rrii into pieces such that it is easily reconstructable 
from pi pieces, but even complete knowledge of pi — 1 pieces reveals absolutely no information 
about rrii, then we can propose a new protocol. This is really easy: let 

Pi 

rrii = (J) niij = mn m i2 • • • m ipi (3) 
j"=i 
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Then mi could only be recovered with all pi m^'s. However, this division scheme is not 
very efficient since rrtj can be very long. Also, for this case, instead of downloading the 
encrypted data from the website, the receiver has to learn all he needs from the sender. So 
we slightly revise our idea and comes up with protocol 2: 

Protocol 2 

In this protocol, the sender has n pairs of different keys, denoted by Ki(i € {1, 2, • • • ,n}). 
Intuitively, she intends to encrypt rrtj with i-Q. 

Input: The receiver's input is composed of k numbers o\, 02, . . . , Ok € {1, 2, . . . , n}, and 
the sender's input is composed of n items mi, 772-2, • - - , n^n, the weight of item m» is p%. 

Output: The receiver's outputs are m ai , m a2 , . . . , m ak . 

• Step 1 The sender encrypts the items mi, mi, • • • , m n with the encryption keys and 
obtains E Kl (mi),^ (m 2 ), • • • , E Kn (m n ). 

• Step 2 The sender sends all the ciphertexts to the receiver. 

• Step 3 For every i G {1, 2, • • • , n}, the sender divides Ki into pi parts. This is done 
by finding Ka,K i2 , ■■ ■ , K ipi such that 0^~f = Ki. 

• Step 4 Using oblivious transfer, the sender leaks K ai , • • • , K ak to the receiver while 
learning nothing about <7j's. This is done by revealing ^Lp^ parts (i.e., the parts 
of key K ai 's) out of all Yli=iPi parts(i.e., for every cr i; reveal K ail , ■ ■ ■ ,K aiPa .). 

• Step 5 The receiver recovers the keys for all m ai 's by exclusive-oring m ai j and de- 
crypts them. 

Similarly, when the protocol is applied by databases, the first three steps are done before 
transactions. That is, the database publishes the encrypted items online and everyone could 
download them. When interested in some of the items, the user interacts with the database 
operator and completes the last two steps. 

Now we show that protocol 2 is indeed a weighted oblivious transfer: If both parties 
behave properly, then the receiver would learn all parts of K ai ,i G {1, • • • , k}, and by XOR 
operations he learns K ai , thus able to learn m ai . 

The scheme takes only three rounds. This is almost optimal since at least the receiver 
has to choose {o"i, • • • , <7fc}'s and let the sender know and the sender has to respond to the 
receiver's request. 

For computation, the receiver needs k < n decryptions and Ym=i P°i XOR operations. 
The sender needs n encryptions, n XOR operations and choosing YH=i(Pi ~ 1) random 
numbers. 
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Lemma 1 For protocol 2, the receiver's choice is unconditional secure, assuming that 
the oblivious transfer used in step 4 is secure. 

Proof. For any choices {a a i}, if ^2Va ai = holds, in step 4 the receiver and 

the sender still perform ^p^-out-of-^pj oblivious transfer, then the security of oblivious 
transfer used in step 4 shows that the sender cannot learn anything-it cannot tell {o~ a i} 
from Since the receiver sends nothing else, the sender cannot tell what the receiver's 

choice is.D 

Lemma 2 For protocol 2, if the receiver is semi-honest, it gets no information about 
rrii,i £ {(Tii ' ' ' > a k}> assuming the security of the encryption scheme and oblivious transfer. 

Proof. If the receiver is semi- honest, due to the security of oblivious transfer, it learns 
nothing about Ki,i £ {<ti, • • • , a^}. The security of the encryption scheme promises that 
EKi{mi),i £ {o"i, • • • , <7fc} is computational indistinguishable from Exi{r),i ^ {a\, • • • , Ofc}, 
where r is a randomly chosen sequence. □ 

Lemma 3 Protocol 2 meets the requirement of sender's privacy assuming the security 
of oblivious transfer used in step 4- 

Proof. For each malicious receiver R in the real run, we construct a simulator R' in 
the Ideal Model such that the outputs of R and R' are computationally indistinguishable. 

As the oblivious transfer used in step 4 is secure, there exists a simulator R" in the Ideal 
Model such that the outputs of R and R" are computationally indistinguishable. Now let 
R' acts the same as R", then R and R' are computationally indistinguishable. Since there 
is no other iteration with T, we prove the theorem. □ 

With these preparations, we come up with: 

Theorem 1 Protocol 2 is indeed weighted oblivious transfer. 

Since the fact that OT% can be achieved from weighted oblivious transfer is trivial, we 
see the equivalence between the two flavors. Moreover, all (existing) flavors of oblivious 
transfer are equivalent in the information theoretic sense. 



2.2. Reducing the computation complexity 

The computational complexity of the protocol is much more expensive than a tradi- 
tional A:-out-of-n scheme where every item has the same weight. This deficiency may, to 
some extent, affect the application of the protocol, but there are some ways to reduce the 
computational complexity. 
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If px , ■ ■ ■ ,p n share a greatest common divisor q > 1 , then by dividing q and paying q 
times the money for each decryption, the weight of the i-th element becomes Pi/q, where 
Pi is the original weight, and the times of encryptions and decryptions can be decreased 
to 1 jq (of the original one) . In the cases that the greatest common divisor of p\ , • ■ ■ , p n is 
l(q = 1), we introduce two additional methods: 

Method 1 Arrange the items into some certain categories, and the items of each 
category share the same weight. This is practical in everyday life. Assume that there are 
three categories, with weight one, two and three, then the computation is around 3ra. 

Method 2 Generally speaking, methods one could save most computation. In the cases 
where it is difficult to arrange the items into certain categories, we have following method: 

First consider an example. Assume that there are four items with weights 105, 190, 307, 
689. Then the greatest common divisor of the weights is q = 1, and we could do nothing 
with them. However, if the weights change a little into 100, 200, 300, 700, then p = 100, 
and the complexity can be greatly reduced by changing the weights into 1, 2, 3, 7. 

More generally, suppose that the weight of each item is pi(i = 1,2, ... ,n). The two 
parties could decide a "greatest common divisor" q, and calculate the new weights-the 
closest integer oipi/q. In this way, the complexity could also be greatly reduced. 

3. Concluding remarks 

This paper discusses weighted oblivious transfer, which can be used for selling priced 
digital goods. Two implementations of it was proposed and analyzed. The protocol is 
especially useful when the prices of the items are not very large, or the prices of digital 
goods fall in very limited categories. In this way, the computation can be done most 
efficiently. 

However, weighted oblivious transfer also suffers from shortcomings. We assume that 
subset problem is hard to compute, but sometimes it is possible (recall the example that 
the prices are 1, 2, • • • , 2 n_1 ). And this shortcoming is unsolvable even when we apply the 
trusted third party. In addition, sometimes the whole price of the digital goods itself can 
leak part (not all) of the choices, which would also not be secure. Similarly, the problem 
exists even a trusted third party is employed. This additional asks the sender to be careful 
when assigning the prices for the goods. 

I think that the above problems are unsolvable in current settings. However, the idea 
can be used for SPIR, when there are more than one servers. Further we may consider the 
implementation of adaptive queries in the future. 
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